A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the xerographic reproduction by anyone of the patent document or the patent disclosure in exactly the form it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
The present invention relates generally to transaction processing, and more particularly to techniques for identifying whether an imported transaction is associated with a parent transaction that was exported by the same transaction processing system that received the imported transaction.
A transaction is most often defined as an explicitly delimited operation, or set of related operations, that change or otherwise modify the content of an information collection (e.g., database or databases) from one consistent state to another. Changes are treated as a single unit in that all changes of a transaction are formed and made permanent (the transaction is xe2x80x9ccommittedxe2x80x9d) or none of the changes are made permanent (the transaction is xe2x80x9cabortedxe2x80x9d). If a failure occurs during the execution of a transaction, resulting in the transaction being aborted, whatever partial changes were made to the collection are undone to leave it in a consistent state.
A transaction processing system typically includes a transaction manager (TM); a collection of subsystems, called resource managers (RMs), which are essentially abstractions of available services, such as database systems; application programs; and the like. The transaction processing system provides a way to interconnect applications and resource managers while maintaining data integrity and transactional consistency.
The application process initiating a transaction invokes various services and/or resource managers to perform various operations and tasks necessary to complete the transaction. All services and resource managers invoked to perform operations for the transaction register with a transaction manager, stating that they are joining the transaction. A transaction manager typically provides transaction management functions, such as monitoring the progress of the transaction and coordinating the commit processing and rollback of the transaction, and protects the integrity of user data. When all operations, or work, have completed, the initiating application process notifies the transaction manager of this fact. The transaction manager then initiates an agreement protocol to coordinate commitment processing among all services and resource managers (including foreign transaction managers) participating in the transaction. In transaction processing the standard agreement protocol is the two-phase commitment (2PC) protocol. A description of the 2PC protocol, as well as a detailed overview of transaction processing, is presented in J. Gray et al., Transaction Processing Concepts and Techniques, Morgan Kauffman, 1993, the contents of which are herein incorporated by reference.
Briefly, in phase one of the 2PC protocol, the transaction manager issues a request prepare signal to each participant (i.e., the transaction manager asks each participating service or resource manager if it believes the operations it performed to be a consistent and complete transformation). If any participant votes no, the commit fails and the transaction is aborted and rolled back; if all participating resource managers vote yes (ready to commit), the transaction is a correct transformation and phase two commences. In phase two of the 2PC protocol, the transaction manager issues a commit request signal informing each participant that the transaction is complete, and records this fact in the transaction""s log. After all participants acknowledge the commit request, the transaction manager records this fact and forgets about the transaction.
Recently, a Transaction Internet Protocol (TIP) that uses the 2PC paradigm has been proposed by the Internet Engineering Task Force (IETF). Attached hereto, as Appendix A, is the final version of the IETF paper describing TIP and its requirements. The IETF paper describes a simple 2PC protocol applicable to transactions involving resources in a distributed, Internet-connected transaction. Basically, two models are described: a xe2x80x9cPushxe2x80x9d model and xe2x80x9cPullxe2x80x9d model.
In the Push model, an application on a first transaction processing system requests that the transaction manager of that system xe2x80x9cexportxe2x80x9d a transaction, T1, to a second transaction processing system to perform some work on behalf of the application. The transaction manager of the first system xe2x80x9cpushesxe2x80x9d transaction T1 to the second system by sending a message to the transaction manager of the second system. The message requests that the second system start a local transaction associated with transaction T1 as a subordinate of the first system, and return the name, for example xe2x80x9cLT1xe2x80x9d, for that local transaction branch on the second system together with the Internet address of the local transaction branch. The transaction manager forwards to the application the name, LT1, and the internet address of the transaction on the second system associated with transaction T1. The application then sends a message to the desired application on the second system, asking it to xe2x80x9cdo some work, and make it part of the transaction that your transaction manager already knows of by the name of LT1.xe2x80x9d Additionally, the first and second transaction managers each update a global map by associating the global transaction T1 initiated on the first system with the exported transaction branch LT1. The global map is a data structure that is typically maintained by each transaction manager in order to associate any and all remote transaction branches, such as LT1, with associated global transactions, such as T1. Because the first system""s transaction manager knows that it sent the transaction to the second system""s transaction manager, the first system""s transaction manager knows to involve the second system""s transaction manager in the 2PC process.
In the Pull model, an application on the first system merely sends a message to an application on the second system, requesting that it xe2x80x9cdo some work, and make it part of a transaction that my transaction manager knows by the name of T1.xe2x80x9d The application on the second system then requests that its transaction manager enlist in the transaction T1. The second system""s transaction manager xe2x80x9cpullsxe2x80x9d transaction T1 over from the first system and initiates a local transaction, LT1, associated with transaction T1. Also, both transaction managers each update their system""s global map. As a result of the pull, the first system""s transaction manager knows to involve the second system""s transaction manager in the 2PC process.
In both the pull and push models, a resource on the second transaction processing system may xe2x80x9cloop backxe2x80x9d a transaction by exporting transaction LT1 to the first transaction processing system to perform work on behalf of transaction LT1. For example, a resource on the second transaction system may send a pull request message to a second application on the first transaction processing system requesting that the second application xe2x80x9cdo some work, and make it part of a transaction that my transaction manager knows by the name LT1.xe2x80x9d The second application then requests that its transaction manager enlist in the transaction LT1. The first system""s transaction manager will check its data structure, for example its global map, and will see that transaction LT1 is associated with transaction T1, which was initiated locally on the first transaction processing system. Rather than pulling the transaction LT1 over from the second system, the first system""s transaction manager will return transaction T1 to the second application, so that the second application performs the requested work under transaction T1. Similarly, if a push request is sent from the second system to the first system""s transaction manager, the first system""s transaction manager will perform the lookup and will see that transaction LT1 is associated with transaction T1. The first system""s transaction manager will then initiate the work at the second application under transaction T1, and respond to the second system by issuing an appropriate response, such as an xe2x80x9calready pushedxe2x80x9d response. In both examples of a loop-back transaction described above, the first system""s transaction manager performs a lookup to determine whether the imported transaction is associated with a parent transaction exported by the first system.
The present invention provides systems and methods for identifying whether a transaction imported to the local transaction processing system from a remote transaction processing system is subordinate to a parent transaction initiated by the local transaction processing system (i.g., a loop-back transaction). In particular, the present invention provides techniques for identifying in the gateway processes or application processes whether an imported transaction is a loop-back transaction, and if so performing work for the imported transaction under the parent transaction.
According to the invention, upon receiving a work request from a remote transaction processing system, an endpoint identifier included as part of the remote transaction identifier is analyzed to determine whether a parent transaction was initiated at the local transaction processing system. If the endpoint identifier indicates that the transaction was initiated in the local transaction processing system, the transaction identifier is analyzed to determine the identity of the parent transaction. Pull requests are typically sent directly to the desired application process by the remote transaction processing system and push requests are typically sent to the local transaction manager through a gateway process. In the pull case, the application process that receives the request is configured to analyze the global transaction identifier and determine the identity of the parent transaction, and in the push case, the gateway process that receives the request is configured to analyze the global transaction identifier and determine the identity of the parent transaction. Work is thereafter performed according to the work request under the parent transaction such that a new transaction is not initiated.
According to an aspect of the invention, a method is provided for detecting a loop back of a transaction in a transaction processing system having a transaction manager (TM) and an application process. The method typically comprises the steps of creating a local transaction in the transaction processing system by the TM, the local transaction having an associated first transaction identifier (TXID); performing work for the local transaction by the application process; sending a first work request associated with the local transaction to a remote transaction processing node; wherein the first work request includes a global transaction identifier (G1) associated with the local transaction, and wherein G1 encodes the first TXID; and receiving a second work request associated with a remote transaction from the remote transaction processing node, wherein the remote transaction is subordinate to the local transaction, wherein the second work request includes G1. The method also typically comprises the steps of determining whether G1 is associated with a transaction created by the first transaction processing system; and if so decoding a portion of G1 so as to obtain the first TXID.
According to another aspect of the invention, a transaction processing system is provided that is communicably coupled to one or more remote transaction processing nodes. The system typically comprises a transaction manager (TM), wherein the TM creates a local transaction having an associated first transaction identifier (TXID), and wherein the local transaction is exported to a first one of the remote transaction processing nodes. The system also typically comprises an application process, wherein the application process receives a work request associated with a remote transaction from one of the first remote transaction processing node and a second remote transaction processing node, wherein the remote transaction is subordinate to the local transaction, wherein the work request includes a first global transaction identifier (G1) associated with the local transaction, and wherein G1 encodes the first TXID, wherein the application process determines whether G1 is associated with a transaction created by the TM; and if so the application process decodes a portion of G1 so as to obtain the first transaction identifier (TXID).
According to yet another aspect of the invention, a transaction processing system is provided, which is communicably coupled to one or more remote transaction processing nodes. The system typically comprises a transaction manager (TM) and an application process that performs work for a local transaction, wherein the TM creates the local transaction which has an associated first transaction identifier (TXID), and wherein the local transaction is exported to a first one of the remote transaction processing nodes. The system also typically includes a first gateway process, wherein the first gateway process receives a push request associated with a remote transaction from one of the first remote transaction processing node and a second remote transaction processing node, wherein the remote transaction is subordinate to the local transaction, wherein the push request includes a first global transaction identifier (G1) associated with the local transaction, and wherein G1 encodes the first TXID, wherein the first gateway process determines whether G1 is associated with a transaction created by the TM; and if so the first gateway process decodes a portion of G1 so as to obtain the first TXID.
Reference to the remaining portions of the specification, including the drawings and claims, will realize other features and advantages of the present invention. Further features and advantages of the present invention, as well as the structure and operation of various embodiments of the present invention, are described in detail below with respect to the accompanying drawings. In the drawings, like reference numbers indicate identical or functionally similar elements.